Distributed resources and services are key to e-business-on-demand infrastructures, which are increasingly required, when competing with the rapidly developing communication within electronic networks, and in particular the Internet.
In order to introduce the most relevant terms used for the present invention, the following explanations are given first:                Resource                    Generalization for the consumption of CPU time, HD space, network bandwidth, applications, etc.                        Distributed Resource                    Resources that do not consume CPU, space, etc. on the same deployment as the client of the resource. Distributed resources often expose web services interfaces.                        Web Service                    Resource that exposes an interface that is accessible over a network, e.g. the Internet.                        Composite Service                    A service that adds value by orchestrating other services and/or resources.                        eBusiness-on-Demand                    Consists of compositions of a potentially large number of distributed resources.                        
WSRP is the abbreviation of Web Services for Remote Portlets, sometimes defined as “Dynamic plug-ins for portal pages”. Officially ratified as an OASIS standard in September 2003, WSRP defines how to plug remote web services into the pages of online portals and other user-facing applications. This allows portal or application owners to easily embed a web service from a third party into a section of a portal page (a ‘portlet’). The portlet then displays interactive content and services that are dynamically updated from the provider's own servers. Formerly known as Web Services for Remote Portals, WSRP is closely allied with WSIA (Web Services Interactive Applications).
The Web Services Description Language (WSDL) is an XML-based language used to describe the services a business offers and to provide a way for individuals and other businesses to access those services electronically. WSDL is the cornerstone of the Universal Description, Discovery, and Integration (UDDI)-initiative spearheaded by Microsoft, IBM, and Ariba. UDDI is an XML-based registry for businesses worldwide, which enables businesses to list themselves and their services on the Internet. WSDL is the language used to do this.
WSDL is derived from Microsoft's Simple Object Access Protocol (SOAP) and IBM's Network Accessible Service Specification Language (NASSL). WSDL replaces both NASSL and SOAP as the means of expressing business services in the UDDI registry.
The resources communicate with each other via data-oriented web services interfaces. More particularly, they provide data-oriented web service interfaces that allow client applications to access and use the interfaces. Composite services can be created and exposed as a new service that orchestrates existing services together. Each such service requires specific configuration that needs to be manageable by an administrator. Due to the possibly complex nature of the service the configuration process is generally also complex, demanding service specific business logic.
Approaching now to the focus of the present invention, creating a user-interface, further abbreviated as UI, for the management of such services is a complex task today because the UI portion (e.g. a prior art servlet or a portlet) needs to be specific for the service and needs to contain knowledge about the relationship of the configuration data it visualizes. If the UI portion is located on a different server than the resource itself, this tight coupling makes it hard to maintain and develop consistent and stable configuration U's. With the advent of e-business-on-demand infrastructures the number of services and resources that needs to be managed will become very large and dynamic. This makes the task of providing well integrated configuration UIs a tedious, if not impossible enterprise. A straight-forward way to solve this problem would be the definition of a set of interfaces and protocols that are suitable for representing configuration data and its internal semantic in a generic way. This would allow for the creation of generic U's for all types of configuration. However, such a protocol would be very complex. In addition, it could not account for resource or service specific UI requirements that cannot be expressed as relationship between data. An example is branding associated with the service.
The general problem underlying the present invention is thus as follows:
A human end-user needs to administer a series of remote resources of different kind that make up his grid. The end-user uses his UI platform, e.g. a desktop, a standard web browser or a portal server, as a front-end to the resources' administration UI.
The integration of service-specific UI elements according to prior art can be described as follows:
Each individual resource provides a resource specific UI-artifact that is installed onto the end-user's UI platform. In case this platform is a desktop based system, such an artifact could be a standalone application per single resource. The user needs to launch multiple applications, configure them with the identification of the remote resource (e.g. IP address and port) in order to administer the resource. The application uses a proprietary way to communicate the settings to the resource and displays the current settings using the desktop's widget set. In case the user is operating on a portal system the resource provides a resource-specific portlet. Although this portlet is integrated into the portal platform and thus participates in a common look-and-feel with other portlets, each resource requires its own administration portlet to be installed, because the portlet communicates in a proprietary way with the resource.
Both prior art scenarios have in common that there is a unique piece of software installed on the UI platform of the end user. If new resources get added to the e-business-on-demand infrastructure, respective new software needs to be installed on the UI platform. This fact tightly couples the topology of the e-business-on-demand infrastructure with the software basis on the UI platform, what imposes huge maintenance costs to keep both synchronized. In addition, updates to the remote resources can introduce new configuration options of these resources that in turn require software updates to the administration component. For large systems with hundreds of remote resources, such scenarios quickly become un-maintainable.
FIG. 1 depicts a respective prior art scenario. This Figure shows how distributed resources communicate with an UI framework by providing resource-specific administration UI artifacts. All artifacts are distinct and need to be installed on the UI framework.
The remote resources (above the horizontal line, in the “remote” area), i.e. a Shopping Web service 210, a composite Web service 220, a Supplier Web service 260, a Delivery Web Service 280 and a Rating Web Service 250 communicate with each other using data-oriented web services interfaces, denoted as “DATA/IF”. Their plumbing forms the e-business-on-demand infrastructure. Each individual service however, needs administration, the “Shopping” service e.g. needs the setup of the offered products, the “delivery” service needs to be configured with the tracking database to user, the “composite” service contains information about the secondary services it orchestrates that need to be configured, etc.
The end user 240 uses a portal server 270 at the UI platform. In order to administer, i.e. manage e.g. the “Shopping” service 210 there needs to be a piece of code, e.g. a portlet be installed on the portal server 270 for this particular service, here denoted as the shopping proxy, 290. The administrator of the portal server needs to install this proxy 290 and update it, whenever the shopping service 210 is updated. In addition, as the administrator of the portal server 270 is in general different from the administrator of the e-business-on-demand infrastructure, both persons need disadvantageously to communicate and agree to an intended proposed maintenance or management action. The same is true for the administration work associated with the other services 220, 250, 260, 280 and their respective Administration Portlets 230, 265, 285, as far as they are depicted in the drawing.
According to prior art the administration of web services is achieved via a standardized, data-oriented API, as follows:
The Distributed Resource Management Application API (DRMAA) Working Group (see http://www.drmaa.org) has developed a specification that allows distributed resources to provide a data-oriented administration API, see the chapter: “Develop an API specification for the submission and control of jobs to one or more Distributed Resource Management (DRM) systems”. The scope of this specification is all the high-level functionality, which is necessary for an application to consign a job to a DRM system including common operations on jobs like termination or suspension. The goal of this prior art specification is to facilitate the direct interfacing of applications to today's DRM systems by application's builders, portal builders, and Independent Software Vendors (ISVs). This prior art specification allows the development of UI-artifacts, UI fragments, controls, etc., that are common to many (probably all) distributed resources and use the DRMAA interface to communicate. In contrast to the approach discussed in the previous section, such a common administration interface reduces the maintenance effort on the UI side significantly. The common UI artifact only needs to be installed once on the UI platform. It still needs to be configured to administer each individual resource, although changes or updates in the resource do not require updates on the client side artifact, as a modification in administrable data is communicated via the DRMAA interface. The shortcoming of this solution, however, lies in the fact that generic administration UIs will not meet the requirements of all resources for the following reasons:
First, resource providers want branding elements in their UI. This type of information—as not related to the administrable properties of a resource—cannot be covered with the DRMAA management interface.
Second, resource providers have constraints in how the administrable data is presented to the end-user. While data-oriented constraints such as interdependencies between values can be expressed programmatically, constraints that require the use of specific UI elements cannot be expressed. For example, the temperature of a heating system must only be displayed using a slider control and not be displayed as an editable value, in order to provide for error-free and consistent data input.
Third, and even quite important, resource providers do not want to expose the administrable data directly, but only want to allow end-users to manipulate the data. Reasons reach from security considerations to the protection of intellectual property.
It is an objective of the present invention to offer a facility for the administration of network resources, which is easier to use and alleviates the shortcomings sketched out above.